-
Notifications
You must be signed in to change notification settings - Fork 136
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add flags for CR0, CR4 and XCR0, as well as extra checks for modification of XCR0 #272
Conversation
Signed-off-by: Ethin Probst <ethindp@protonmail.com>
Signed-off-by: Joe Richey <joerichey@google.com>
Signed-off-by: Joe Richey <joerichey@google.com>
Signed-off-by: Joe Richey <joerichey@google.com>
Signed-off-by: Joe Richey <joerichey@google.com>
This function only throws a #UD, which we generally consider to be safe. Also, add an `Exceptions` section to the `Segment64` docs (this is similar to the `Panic` section in normal Rust docs). Signed-off-by: Joe Richey <joerichey@google.com>
Signed-off-by: Joe Richey <joerichey@google.com>
Signed-off-by: Joe Richey <joerichey@google.com>
Signed-off-by: Joe Richey <joerichey@google.com>
Signed-off-by: Joe Richey <joerichey@google.com>
Add common abstractions for x86 Segments
This ensures that the arguments are passed by RDI, RSI, RDX, RCX, etc.
… as extra checks when writing to XCR0. Signed-off-by: Ethin Probst <ethindp@protonmail.com>
If this is a breaking change, can you open this PR against the |
Oh. Sure. Is there a way I can just shift the PR to the next branch? Or will I need to reopen it? |
I think I can rebase it onto the next branch |
Actually, it looks like this is your master branch, so I don't want to mess it up. I changed the base to |
Closing in favor of #273 |
This PR adds some extras to the three control registers
CR0
,CR4
, andXCR0
. It also adds some checks for XCR0. (We could extend this to other registers as well.)Bits added
Checks
This PR adds invariant checks that cannot be disabled via the
assert!
macro when using thewrite()
function on theXCr0
type. Primarily, these invariants enforce those listed on pg. 2-20 of volume 3A of the intel SDMs; they disallow attempts to:I missed the initial invariant (that setting any reserved bits causes a general-protection fault) but I will add that if you guys would like me to (somebody else can do so as well). We should probably consider enforcing all invariants on all control registers to catch problems like this before they arise and generate exceptions, since these APIs are supposed to be "safe". This PR unfortunately has a few breaking changes as well.
Breaking changes
In order for CR4.PKS to coexist with CR4.PKU and for the documentation to make sense, I was forced to rename CR4.PKU to
PROTECTION_KEY_USER
. I also renamedXCr0Flags::YMM
toXCr0Flags::AVX
to make the names match with the documentation. I hope you guys don't mind.